Many prior art database management systems associate software objects by specifically defined relationship types.
The prior art includes U.S. Pat. No. 7,149,751 that discloses a system and method for distributing selected objects from a source database to a destination database; U.S. Pat. No. 7,000,017 that presents a system and method for distributing a selected object and for automatically distributing the objects that are associated with the selected object; U.S. Pat. No. 6,877,159 that teaches an apparatus and method for maintaining object associations in an object oriented environment; U.S. Pat. No. 6,456,995; that discusses a system, method, and computer program products for ordering objects; U.S. Pat. No. 6,101,502 that discloses an object model mapping and runtime engine for employing relational database with object oriented software; U.S. Pat. No. 5,854,750 that presents a system and method for processing transactions in an environment containing a number of object oriented applications; United States Patent Application Publication No. 20060236380 that teaches of a system and method for grouping device or application objects in a directory service; United States Patent Application Publication No. 20060200662 that discusses referencing objects in a virtual environment; United States Patent Application Publication No. 20060277202 that discloses a system and method for performing object association using a location tracking system; and United States Patent Application Publication No. 20020107872 that presents an object manager for a common information model.
Each and every patent and patent application publication document referenced herein is incorporated by reference within this disclosure in their entirety and for all purposes, to include U.S. Pat. Nos. 7,149,751; 7,000,017; 6,877,159; 6,456,995 6,101,502; 5,854,750 and United States Patent Application Publication No.'s 20060236380; 20060200662; 20060277202; and 20020107872.
In the prior art, an object-oriented database might include an employee record software object for each employee of a company. The employee record objects might all be of a same type number and each individual object might be intended to include personal information and employment data related to a specific employee. Relationships such as “supervisor” and “subordinate” may be defined by the database management system and used to relate software objects within the database.
Certain prior art database management systems build a listing of software objects related to a particular software object (hereafter “parent object”). and associate the listing with that parent object. The listing may be maintained within the schema of the parent object or outside of the parent object structure.
A listing may be maintained within an ordered list or vector such as a variable length array, wherein the variable length array includes a plurality of key pairs. Each key pair may include (1.) an object identification serial number (hereafter “OID”) of a software object, and (2.) a data specifying the type of relationship that exists between the software object identified by the OID stored in the pair and the parent object.
Prior art search techniques access the listing in the execution of searches. The listing may be read by the database management system (hereafter “DBMS”) in an order from first key pair to last key pair. The order of the key pairs within the listing therefore determines how much time passes and computational resource is expended before a key pair that satisfies a given query is located. Yet the ordering of the key pairs within the listing may be inconsistently related to the likelihood of a key pair satisfying a query within an operational environment. For example, the first key pair in a listing may include the OID of an education record software object that includes educational data concerning the employee of the parent object, and a datum that identifies the relationship defined between the parent object and the education record software object by the DBMS as being an EDUCATION relationship. Yet, this educational information key pair may be examined by every DBMS query execution that accesses the key pair listing of the parent object, while satisfying less than one in a million executed queries that examine the instant listing.
There is therefore a long felt need to store information identifying both (1.) OID's of objects having relationships with a particular software object, e.g., the parent object, and (2.) the types of relationships existing between each noted OID the same particular software object, by techniques and systems that improve the responsiveness and computational efficiency of a DBMS.